三菱重工「初めてのAWS活用IoTサービス開発とリリースに至るまで」で明かされた短期間＆未経験者の開発ノウハウ #devio_showcase

「3ヶ月でアレとコレとソレを作って下さい」

最近のビジネス環境において、「まずは3ヶ月」というキーワード、非常によく出てきます。自分もいろんなお客様と話をする中で「検討にばかり時間をかけずに、まずは3ヶ月で形にして欲しい」という要望を非常によく伺います。

ただ、実際に新しいものを新しい技術で未経験者中心で進めていくにあたって、3ヶ月という期間はあまりにも短いというのが現実ではないでしょうか。

今回、弊社主催のDevelopers.IO Showcaseで、三菱重工様の「初めてのAWS活用IoTサービス開発とリリースに至るまで」を聴講しながら、そんなことを切実に考えていました。

ユーザー企業の中で、新しいサービスや機能を開発し運用していく上で必要な考え方やノウハウが詰まったこのセッション、是非同じ境遇に立たされている方に見ていただいて、みなさんの現場で活かしていただければと思います！

3ヶ月って無茶振りすぎでは…!!

　 ( ﾟдﾟ)　ｶﾞﾀｯ
　 /　　 ヾ
＿_L| /￣￣￣/＿
　 ＼/　　　/

社会人にはな、やらなければいけないときが、ある、あるんだよ…

なお、レポート内容の詳細やサービスについてのご相談がございましたらクラスメソッドの担当エンジニアが承ります。下記のフォームにてご入力ください。

クラスメソッドに相談する

セッション概要

「初めてのAWS活用IoTサービス開発とリリースに至るまで」

三菱重工では様々な産業機械の開発と運用保守を行っていますが、これまでクラウドを活用したリモートモニタリングやメンテナンスが進んでいませんでした。今回クラスメソッド様の協力のもと、産業機械のIoT化をAWSおよびAuth0などの各種サービスを活用して構築し、世界中のカスタマー・サービスマンが利用可能なリモートモニタリング・メンテナンスサービスダッシュボードをリリース致します。本ウェビナーでは本サービスダッシュボードを構築するまでに活用したAWSと各種サービスの活用内容とクラスメソッド様の支援内容をご紹介致します。

講演者

三菱重工業株式会社 成長推進室デジタルエクスペリエンス推進グループ 上席主任 西尾創氏

セッションアジェンダ

今回のセッションの対象聴講者はタイトルにもあります通り「初めて」がポイント。これからAWSのサービスを利用される方や、IoT関連のサービスを構築される管理者の方やエンジニアの方に参考になる内容かと思います。

1. 自己紹介
2. 会社紹介
3. デジタルエクスペリエンスデザインについて
4. ふたつのIoTについて
5. IoTでやりたかったこと
6. 3ヶ月でやりきるアーキテクチャ検討
7. その後と本日のまとめ

1. 自己紹介　

どうも、三菱重工業株式会社の西尾と申します。新卒で製造系のコンサルベンチャーに入社後、2009年から現職です。

未経験ですが、実はデジタルエクスペリエンスデザイングループ発足時のメンバー全員がクラウド未経験に近く、ITも専門ではなく、部署全体が手探りの状態からのスタートなります。

2. 会社紹介

現在、三菱就航の事業領域は大きく3つで成り立っています。

これらの事業部門が事業会社が進められ、現在は半分が事業会社になっており、それによって、事業運営が機動的になるというメリットがありました。経営資源が分散されるため、ビジネスITへの注力が難しいという経営課題がありました。

そこでホールディングカンパニーの直属として、デジタルエクスペリエンスデザイン部では、企画から開発、運用までを内製化で行うように取り組んでいます。次に、我々のグループの目的と目標を紹介します。

現在、三菱重工全体の目標として、TOP（Triple One Proportion）として、売上と時価総額と総資産の比率を同じにするようにすすめています。このうち、デジタルエクスペリエンスデザイン部は、各事業会社の収益性を上げていくところに注力しています。

3. デジタルエクスペリエンスデザインについて

次に、本部署で対応するシステム領域です。まずは、カスタマーポータルをとIoTを中心に開発を進めています。本日説明するのは、このIoT部分の説明が主になります。

4. ふたつのIoTについて

扱うIoTですが、大きく2種類に分けられます。

• マシナリー系IoT（産業機械類）
  • 複数工場に複数台納品するため、稼働数は多くなる
  • 機械自体が大きいため、データ点数はさほど多くない
• プラント系IoT（産業プラント類）
  • 稼働数自体は少ない
  • 工場全体のデータをもつため、データ転送が膨大になる

こういったデータの特性のなかで、それぞれのIoTに対して採用する技術を変えています。

• マシナリー系IoT　→　サーバーレス化
• プラント系IoT　→　コンテナ化 　 今回お話するのは、マシナリー系IoTとなります。

5. IoTでやりたかったこと

私が異動した直後、上層部から受けた指示がこちら。

「3ヶ月3人でそんなのできるの？」と困惑したのをよく覚えています。まずはIoTでやりたいことをまとめてみました。

当時は顧客からの連絡はメールでのみ受け付けていて、実際の機械の状態確認はサービスマンが現場に直接行く必要がありタイムラルがありました。その中で、顧客と弊社側のミスコミュニケーションが蓄積していくという課題があり、この課題をIoTサービスで解決したいという想いがありました。

ただ、3ヶ月という制約があるため、従来と同じやり方では実現できませんし、世の中にあるサービスを使い効率化していくというサブミッションもありました。これらミッションを達成するために、クラスメソッドさんにお願いする体制にすることが決定しました。

実現方法について、クラスメソッドさんと色々相談した結果、「そうですね、なんとかなりますよ」という感触がでてきました。IoTデバイスとの接続はDEDで担当し、AWS上にデータレイクやデータウェアハウスを構築し、データを蓄積していく部分をクラスメソッドさんにお願いしました。また、フロントエンドについては、他のベンダーにお願いすることにしました。

6. 3ヶ月でやりきるアーキテクチャ検討

3ヶ月のマイルストーンがこちら。

全体アーキテクチャは、先程の示した体制全員で検討し、各チームのインターフェース部分を主にすり合わせし実施していきます。詳細部分は、開発を進めていく中で必要があれば適宜変更する前提に進めていき、以下の構成をキックオフから3週間で決定しています。

アーキテクチャのキーポイント

• ネットワークにSORACOMとAWS IoTを採用（客先の環境に左右されない構成）
• IoTデバイスにDeviceGatewayを採用
  • 情報量が少ないため選定には、複数デバイスでのPoCを実施
• データレイク・データウェアハウスにRedShiftを採用

アーキテクチャの変更

一旦この内容で決定したが、アーキテクチャの変更も許容する前提で考えていた。フロントエンドAPIやマスタデータの保存箇所です。

フロントエンドは初めて作るサービスということもあって、性能要件やサービス仕様が本当に必要なものなのか、確実には言い切れない部分でありました。そのため、曖昧な部分を特定するため、簡単に構築できるBIツールを使って、実際に構築してみました。結果的に性能面から使うことが難しいことがわかったので採用はしませんでしたが、まずは作ってみることで曖昧な部分を明らかにするという進め方は良かったなと感じています。

マスタデータは、とりあえずDynamoDBにいれておけば良い想定でしたが、RedShiftと合わせて使う上で不都合がでてきたので、その部分もあとから変更しています。

クラスメソッドさんに頼りきりだったところ

主に、監視、データレイクフロー、インフラの部分はクラスメソッド様にお願いしました。特にステークホルダーとの要求事項の調整が不要であったのと、クラスメソッド様が得意分野だったのが大きな理由です。

コミュニケーション環境の変更

弊社では、コミュニケーション手段として電子メールとOfficeツールを使うことが標準だったのですが、それだけでは今回3ヶ月で推進する中ででコミュニケーションに支障がでるのが見えていたので、新しいこれらのツールを使うことで、コミュニケーションコストを大幅に削減することができました。

なんとかαリリースにこぎつけることができました。

αリリース後の課題

社内管理者やサービスマンに実際に提供することで、想定内、想定外含めた多数の課題を把握することができました。3ヶ月で作った中で不出来な部分もありましたが、まずは実際に作って見せて触ってみてもらうことで得るものも大きかったので、急いで作った甲斐はあったと考えています。

課題をベースに継続改善

EC2上に作ったフロントエンドは、VueやAPI Gateway、Lambdaを使ったREST APIに変更。ユーザー管理もSaaSを活用。これらもα版をリリースするなかでスピード感を持って対応できたので、その効果をまさに実感することができました。

現在は、このシステムも完成していますが、実際につくってみるというアプローチが非常に効果的だったと考えています。

7. その後と本日のまとめ

• 未経験者しかいなかったが、クラスメソッド様とタグを組むことで、アルファリリースを達成することができた
• αリリースやβリリースなどの早期アクセスを前提した進め方を行うことで、実際のリリースという要求に対する対応と、具体的な課題の洗い上げという部分で非常に効果があり、最終的なゴールへのスピードをあげることができる
• 開発サービスと共にコミュニケーションサービスも3rdパーティのものをフル活用することで、迅速な開発が可能となる

以上、本日のセッションとなります。ありがとうございました。

セッション後QA

クラウドに関する経験が無い中、3ヶ月でサービスを立ち上げる際に外部ベンダーから業務支援を受けるために、事前に準備しておくべきことがあれば教えて下さい。

Backlogなどのコミュニケーションツールの導入です。今回は途中から導入することになったのですが、社内稟議を通すのに時間がかかってしまいました。こういったところで時間がかかるとプロジェクト進行上ボトルネックとなってしまうので可能な限り早めに準備しておくのが良いと思います。

クラスメソッドと共同する中で感じたことを率直に教えて下さい。

わりとざっくばらんに仕様の検討を相談できる素地があるのと、開発自体もアジャイルとして勧めていただいているので、変化に対する許容度が高い点がありがたいです。他の会社でウォーターフォールで進めているところでは途中の変更が難しかったり手間がかかるのですが、そういった点が無いので非常に頼もしかったと思います。

SaaSを多く利用されていますが、選定基準はどのように決められたのでしょうか？

SaaSについては、まず最初にクラスメソッド様におすすめのものを聞いた上で試してみるというところでやっていました。もちろん合わないものもありましたが、SaaSなので乗り換えやすいということもあるので、気軽に試してやってみるというスタンスで進めています。

要件定義のフェーズもあったかと思うのですが、そこは自社で進められたでしょうか？未経験ということで技術的に深堀りできなかったところは、クラスメソッドのサポートを受けましたでしょうか？

特にクラウドの要件定義ではクラスメソッド様に助力を受けたところが大きかったです。機能的な要求部分は、主に弊社で決めていました。それをどのようにクラウドの中で構築するかというところで、クラスメソッド様のサポートを受けています。

　

感想「まずはやってみる精神が、一番はやく確実性が高い」

あまりセッション中には大きく語られていなかったように思うのですが、実際問題3ヶ月という短期間かつ未経験チームで成果を出すという中、想像以上にプレッシャーが厳しかったのではないかと思いました。プロジェクト進行も簡単ではなかったと思うのですが、「変更を恐れない」「まずは作ってみる」という姿勢が一貫していたのが非常に伝わってきました。

ビジネスに於いてもITの分野においても、状況は刻一刻と変わりITの手段もどんどん移り変わっていきます。なにか始める時に「3ヶ月」というタイムスパンは非常によく出てくるのではないでしょうか。そういう中で成果を出しつつプロジェクトを進めていくための秘訣がこのセッションには詰まっていたと感じました。

似たような状況で成果を求められるすべての人に、参考になるセッションだと思います。

それでは、今日はこのへんで。濱田（@hamako9999）でした。